`<array>`: `std::array<T,0>` calls constructors and destructors of `T`

[eisenwave]

Describe the bug

STL/stl/inc/array

Lines 761 to 763 in 7841cf8

	conditional_t<disjunction_v<is_default_constructible<_Ty>, _Is_implicitly_default_constructible<_Ty>>, _Ty,
	_Empty_array_element>
	_Elems[1]{};

A std::array<T,0> is meant to be an array of zero elements, but it's actually an array of one element as long as T is default-constructible in this implementation. This is clearly non-compliant.

Command-line test case

C:\Temp>type repro.cpp
#include <array>
#include <iostream>

struct S { S() { std::cout << "test failure\n"; } };

int main() {
    std::array<S,0> s;
}

C:\Temp>cl /EHsc /W4 /WX /std:c++latest .\repro.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.36.32522 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

/std:c++latest is provided as a preview of language features from the latest C++
working draft, and we're eager to hear about bugs and suggestions for improvements.
However, note that these features are provided as-is without support, and subject
to changes or removal as the working draft evolves. See
https://go.microsoft.com/fwlink/?linkid=2045807 for details.

repro.cpp
Microsoft (R) Incremental Linker Version 14.36.32522.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:repro.exe
repro.obj

C:\Temp>.\repro.exe
test failure

Expected behavior

The program should print nothing.

STL version

7841cf8

Additional context

This is relevant to P3737R0: std::array is a wrapper for an array!

[eisenwave]

Looks like 793713e by @CaseyCarter turned the element type into what it is today; it used to just be

_Ty _Elems[1];

... before that, which is even more wrong.

If the bug was fixed, this would need to be done with some caution because there's a potential ABI break; zero-length arrays that are currently non-trivial could become trivially copyable.

[frederick-vs-ja]

If the bug was fixed, this would need to be done with some caution because there's a potential ABI break; zero-length arrays that are currently non-trivial could become trivially copyable.

The ABI break looks actual and quite severe to me. If we make currently non-trivial array<T, 0> trivial, there'll be mismatch for calling convention, array-new cookie, and behavior on destruction.

[StephanTLavavej]

Yes, this would definitely be an ABI break. I'm surprised we didn't already have an issue tracking this.

[eisenwave]

@StephanTLavavej what's going to happen to vNext issues then? Is there any schedule/plan for this fix?

I'm mainly concerned about how this impact the discussion on P3737; if it's an ABI break to fix this issue anyway, it should be safe to assume that we can standardize a layout for zero-length std::array which is incompatible with the MSVC STL.

[StephanTLavavej]

At this time, there is no plan or ETA for vNext. I believe all of the compiler/library devs would love to make it happen, since we'd get to fix so many issues that have been thorns in everyone's sides for decades, but it has been increasingly difficult to find the time and capacity for a major undertaking that would be inherently disruptive to both development (redirecting energy away from normal feature/fix work) and users (due to the migration costs, even with a gradual strategy). I remember being able to make ABI-breaking changes in the first part of my career (2007-2015) and I hope I'll get that chance again, but I truly don't know if it'll happen before I retire. As always, upvoting DevCom tickets about vNext and ABI-blocked issues is helpful to make this case to management.

I think that, given the existing non-conformance, I have no objection to any Standard proposals that make ABI-breaking changes to std:array<T, 0>, as we are simply forced to implementer-veto that part of a proposal until vNext.